SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Stream processing</title>

</head>

Stream processing

</h1>

</header>

In <a href="Computer_science" title="Computer science">computer science</a>, stream processing (also known as event stream processing, data stream processing, or distributed stream processing) is a <a href="Programming_paradigm" title="Programming paradigm">programming paradigm</a> which views <a href="Stream_(computing)" title="Stream (computing)">streams</a>, or sequences of events in time, as the central input and output objects of <a href="Computation" title="Computation">computation</a>. Stream processing encompasses <a href="Dataflow_programming" title="Dataflow programming">dataflow programming</a>, <a href="Reactive_programming" title="Reactive programming">reactive programming</a>, and <a href="Distributed_computing" title="Distributed computing">distributed</a> <a href="Data_processing" title="Data processing">data processing</a>.<a href="#cite_note-1">[1]</a> Stream processing systems aim to expose <a href="Parallel_computing" title="Parallel computing">parallel processing</a> for data streams and rely on <a href="Streaming_algorithm" title="Streaming algorithm">streaming algorithms</a> for efficient implementation. The <a href="Solution_stack" title="Solution stack">software stack</a> for these systems includes components such as <a href="Programming_model" title="Programming model">programming models</a> and <a href="Query_language" title="Query language">query languages</a>, for expressing computation; <a href="Data_stream_management_system" title="Data stream management system">stream management systems</a>, for distribution and <a href="Scheduling_(computing)" title="Scheduling (computing)">scheduling</a>; and hardware components for <a href="Hardware_acceleration" title="Hardware acceleration">acceleration</a> including <a href="Floating-point_unit" title="Floating-point unit">floating-point units</a>, <a href="Graphics_processing_unit" title="Graphics processing unit">graphics processing units</a>, and <a href="Field-programmable_gate_array" title="Field-programmable gate array">field-programmable gate arrays</a>.<a href="#cite_note-2">[2]</a>

The stream processing paradigm simplifies parallel software and hardware by restricting the parallel computation that can be performed. Given a sequence of data (a stream), a series of operations (<a href="Compute_kernel" title="Compute kernel">kernel functions</a>) is applied to each element in the stream. Kernel functions are usually <a href="Pipeline_(computing)" title="Pipeline (computing)">pipelined</a>, and optimal local on-chip memory reuse is attempted, in order to minimize the loss in bandwidth, associated with external memory interaction. Uniform streaming, where one kernel function is applied to all elements in the stream, is typical. Since the kernel and stream abstractions expose data dependencies, compiler tools can fully automate and optimize on-chip management tasks. Stream processing hardware can use <a href="Scoreboarding" title="Scoreboarding">scoreboarding</a>, for example, to initiate a <a href="Direct_memory_access" title="Direct memory access">direct memory access</a> (DMA) when dependencies become known. The elimination of manual DMA management reduces software complexity, and an associated elimination for hardware cached I/O, reduces the data area expanse that has to be involved with service by specialized computational units such as <a href="Arithmetic_logic_unit" title="Arithmetic logic unit">arithmetic logic units</a>.

During the 1980s stream processing was explored within <a href="Dataflow_programming" title="Dataflow programming">dataflow programming</a>. An example is the language <a href="SISAL" title="SISAL">SISAL</a> (Streams and Iteration in a Single Assignment Language).

<div class="mw-heading mw-heading2"><h2 id="Applications">Applications</h2></div>

Stream processing is essentially a compromise, driven by a data-centric model that works very well for traditional DSP or GPU-type applications (such as image, video and <a href="Digital_signal_processing" title="Digital signal processing">digital signal processing</a>) but less so for general purpose processing with more randomized data access (such as databases). By sacrificing some flexibility in the model, the implications allow easier, faster and more efficient execution. Depending on the context, <a href="Central_processing_unit" title="Central processing unit">processor</a> design may be tuned for maximum efficiency or a trade-off for flexibility.

Stream processing is especially suitable for applications that exhibit three application characteristics:

<ul><li>Compute intensity, the number of arithmetic operations per I/O or global memory reference. In many signal processing applications today it is well over 50:1 and increasing with algorithmic complexity.</li>

<li>Data parallelism exists in a kernel if the same function is applied to all records of an input stream and a number of records can be processed simultaneously without waiting for results from previous records.</li>

<li>Data locality is a specific type of temporal locality common in signal and media processing applications where data is produced once, read once or twice later in the application, and never read again. Intermediate streams passed between kernels as well as intermediate data within kernel functions can capture this locality directly using the stream processing programming model.</li></ul>

Examples of records within streams include:

<ul><li>In graphics, each record might be the vertex, normal, and color information for a triangle;</li>

<li>In image processing, each record might be a single pixel from an image;</li>

<li>In a video encoder, each record may be 256 pixels forming a macroblock of data; or</li>

<li>In wireless signal processing, each record could be a sequence of samples received from an antenna.</li></ul>

For each record we can only read from the input, perform operations on it, and write to the output. It is permissible to have multiple inputs and multiple outputs, but never a piece of memory that is both readable and writable.

<div class="mw-heading mw-heading2"><h2 id="Code_examples">Code examples</h2></div>

By way of illustration, the following code fragments demonstrate detection of patterns within event streams. The first is an example of processing a data stream using a continuous <a href="SQL" title="SQL">SQL</a> query (a query that executes forever processing arriving data based on timestamps and window duration). This code fragment illustrates a JOIN of two data streams, one for stock orders, and one for the resulting stock trades. The query outputs a stream of all Orders matched by a Trade within one second of the Order being placed. The output stream is sorted by timestamp, in this case, the timestamp from the Orders stream.

<div class="mw-highlight mw-highlight-lang-postgresql mw-content-ltr" dir="ltr"><pre>SELECT DataStream

Orders.TimeStamp, Orders.orderId, Orders.ticker,

Orders.amount, Trade.amount

FROM Orders

JOIN Trades OVER (RANGE INTERVAL '1' SECOND FOLLOWING)

ON Orders.orderId = Trades.orderId;

</pre></div>

Another sample code fragment detects weddings among a flow of external "events" such as church bells ringing, the appearance of a man in a tuxedo or morning suit, a woman in a flowing white gown and rice flying through the air. A "complex" or "composite" event is what one infers from the individual simple events: a wedding is happening.

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>WHEN Person.Gender EQUALS "man" AND Person.Clothes EQUALS "tuxedo"

FOLLOWED-BY

Person.Clothes EQUALS "gown" AND

(Church_Bell OR Rice_Flying)

WITHIN 2 hours

ACTION Wedding

</pre></div>

<div class="mw-heading mw-heading2"><h2 id="Comparison_to_prior_parallel_paradigms">Comparison to prior parallel paradigms</h2></div>

Basic computers started from a sequential execution paradigm. Traditional <a href="Central_processing_unit" title="Central processing unit">CPUs</a> are <a href="Single_instruction%2C_single_data" title="Single instruction, single data">SISD</a> based, which means they conceptually perform only one operation at a time.

As the computing needs of the world evolved, the amount of data to be managed increased very quickly. It was obvious that the sequential programming model could not cope with the increased need for processing power. Various efforts have been spent on finding alternative ways to perform massive amounts of computations but the only solution was to exploit some level of parallel execution. The result of those efforts was <a href="Single_instruction%2C_multiple_data" title="Single instruction, multiple data">SIMD</a>, a programming paradigm which allowed applying one instruction to multiple instances of (different) data. Most of the time, SIMD was being used in a <a href="SWAR" title="SWAR">SWAR</a> environment. By using more complicated structures, one could also have <a href="Multiple_instruction%2C_multiple_data" title="Multiple instruction, multiple data">MIMD</a> parallelism.

Although those two paradigms were efficient, real-world implementations were plagued with limitations from memory alignment problems to synchronization issues and limited parallelism. Only few SIMD processors survived as stand-alone components; most were embedded in standard CPUs.

Consider a simple program adding up two arrays containing 100 4-component <a href="Vector_(geometric)" class="mw-redirect" title="Vector (geometric)">vectors</a> (i.e. 400 numbers in total).

<div class="mw-heading mw-heading3"><h3 id="Conventional,_sequential_paradigm">Conventional, sequential paradigm</h3></div>

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>for (int i = 0; i < 400; i++)

result[i] = source0[i] + source1[i];

</pre></div>

This is the sequential paradigm that is most familiar. Variations do exist (such as inner loops, structures and such), but they ultimately boil down to that construct.

<div class="mw-heading mw-heading3"><h3 id="Parallel_SIMD_paradigm,_packed_registers_(SWAR)">Parallel SIMD paradigm, packed registers (SWAR)</h3></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">See also: <a href="Vector_processor#Vector_reduction_example" title="Vector processor">Vector_processor § Vector_reduction_example</a></div>

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>for (int el = 0; el < 100; el++) // for each vector

vector_sum(result[el], source0[el], source1[el]);

</pre></div>

This is actually oversimplified. It assumes the instruction <code>vector_sum</code> works. Although this is what happens with <a href="Intrinsic_function" title="Intrinsic function">instruction intrinsics</a>, much information is actually not taken into account here such as the number of vector components and their data format. This is done for clarity.

You can see however, this method reduces the number of decoded instructions from numElements * componentsPerElement to numElements. The number of jump instructions is also decreased, as the loop is run fewer times. These gains result from the parallel execution of the four mathematical operations.

What happened however is that the packed SIMD register holds a certain amount of data so it's not possible to get more parallelism. The speed up is somewhat limited by the assumption we made of performing four parallel operations (please note this is common for both <a href="AltiVec" title="AltiVec">AltiVec</a> and <a href="Streaming_SIMD_Extensions" title="Streaming SIMD Extensions">SSE</a>).

<div class="mw-heading mw-heading3"><h3 id="Parallel_stream_paradigm_(SIMD/MIMD)">Parallel stream paradigm (SIMD/MIMD)</h3></div>

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>// This is a fictional language for demonstration purposes.

elements = array streamElement([number, number])[100]

kernel = instance streamKernel("@arg0[@iter]")

result = kernel.invoke(elements)

</pre></div>

In this paradigm, the whole dataset is defined, rather than each component block being defined separately. Describing the set of data is assumed to be in the first two rows. After that, the result is inferred from the sources and kernel. For simplicity, there's a 1:1 mapping between input and output data but this does not need to be. Applied kernels can also be much more complex.

An implementation of this paradigm can "unroll" a loop internally. This allows throughput to scale with chip complexity, easily utilizing hundreds of ALUs.<a href="#cite_note-3">[3]</a><a href="#cite_note-4">[4]</a> The elimination of complex data patterns makes much of this extra power available.

While stream processing is a branch of SIMD/MIMD processing, they must not be confused. Although SIMD implementations can often work in a "streaming" manner, their performance is not comparable: the model envisions a very different usage pattern which allows far greater performance by itself.

It has been noted that when applied on generic processors such as standard CPU, only a 1.5x speedup can be reached.<a href="#cite_note-5">[5]</a> By contrast, ad-hoc stream processors easily reach over 10x performance, mainly attributed to the more efficient memory access and higher levels of parallel processing.<a href="#cite_note-6">[6]</a>

Although there are various degrees of flexibility allowed by the model, stream processors usually impose some limitations on the kernel or stream size. For example, consumer hardware often lacks the ability to perform high-precision math, lacks complex indirection chains or presents lower limits on the number of instructions which can be executed.

<div class="mw-heading mw-heading2"><h2 id="Research">Research</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}@media print{body.ns-0 .mw-parser-output .ambox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style>

<a href="Stanford_University" title="Stanford University">Stanford University</a> stream processing projects included the Stanford Real-Time Programmable Shading Project started in 1999.<a href="#cite_note-7">[7]</a>

A prototype called Imagine was developed in 2002.<a href="#cite_note-8">[8]</a>

A project called Merrimac ran until about 2004.<a href="#cite_note-9">[9]</a>

<a href="AT%26T" title="AT&T">AT&T</a> also researched stream-enhanced processors as <a href="Graphics_processing_unit" title="Graphics processing unit">graphics processing units</a> rapidly evolved in both speed and functionality.<a class="external autonumber external" href="https://en.wikipedia.org/wiki/Stream_processing#endnote_GPUasSTREAM">[1]</a> Since these early days, dozens of stream processing languages have been developed, as well as specialized hardware.

<div class="mw-heading mw-heading3"><h3 id="Programming_model_notes">Programming model notes</h3></div>

The most immediate challenge in the realm of parallel processing does not lie as much in the type of hardware architecture used, but in how easy it will be to program the system in question in a real-world environment with acceptable performance. Machines like Imagine use a straightforward single-threaded model with automated dependencies, memory allocation and <a href="Direct_memory_access" title="Direct memory access">DMA</a> scheduling. This in itself is a result of the research at MIT and Stanford in finding an optimal layering of tasks between programmer, tools and hardware. Programmers beat tools in mapping algorithms to parallel hardware, and tools beat programmers in figuring out smartest memory allocation schemes, etc. Of particular concern are MIMD designs such as <a href="Cell_(microprocessor)" class="mw-redirect" title="Cell (microprocessor)">Cell</a>, for which the programmer needs to deal with application partitioning across multiple cores and deal with process synchronization and load balancing.

A drawback of SIMD programming was the issue of <a href="Array-of-structures_(AoS)_and_structure-of-arrays_(SoA)" class="mw-redirect" title="Array-of-structures (AoS) and structure-of-arrays (SoA)">array-of-structures (AoS) and structure-of-arrays (SoA)</a>. Programmers often create representations of enitities in memory, for example, the location of an particle in 3D space, the colour of the ball and its size as below:

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre> // A particle in a three-dimensional space.

struct particle_t {

float x, y, z; // not even an array!

unsigned byte color[3]; // 8 bit per channel, say we care about RGB only

float size;

// ... and many other attributes may follow...

};

</pre></div>

When multiple of these structures exist in memory they are placed end to end creating an <a href="Array_data_structure" class="mw-redirect" title="Array data structure">arrays</a> in an <a href="Array_of_structures" class="mw-redirect" title="Array of structures">array of structures</a> (AoS) topology. This means that should some algorithim be applied to the location of each particle in turn it must skip over memory locations containing the other attributes. If these attributes are not needed this results in wasteful usage of the CPU cache. Additionally, a SIMD instruction will typically expect the data it will operate on to be contiguous in memory, the elements may also need to be <a href="Data_structure_alignment" title="Data structure alignment">aligned</a>. By moving the memory location of the data out of the structure data can be better organised for efficient access in a stream and for SIMD instructions to operate one. A <a href="Structure_of_arrays" class="mw-redirect" title="Structure of arrays">structure of arrays</a> (SoA), as shown below, can allow this.

<div class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr"><pre>struct particle_t {

float *x, *y, *z;

unsigned byte *colorRed, *colorBlue, *colorGreen;

float *size;

};

</pre></div>

Instead of holding the data in the structure, it holds only pointers (memory locations) for the data. Shortcomings are that if an multiple attributes to of an object are to be operated on they might now be distant in memory and so result in a cache miss. The aligning and any needed padding lead to increased memory usage. Overall, memory management may be more complicated if structures are added and removed for example.

For stream processors, the usage of structures is encouraged. From an application point of view, all the attributes can be defined with some flexibility.

Taking GPUs as reference, there is a set of attributes (at least 16) available. For each attribute, the application can state the number of components and the format of the components (but only primitive data types are supported for now). The various attributes are then attached to a memory block, possibly defining a stride between 'consecutive' elements of the same attributes, effectively allowing interleaved data.

When the GPU begins the stream processing, it will gather all the various attributes in a single set of parameters (usually this looks like a structure or a "magic global variable"), performs the operations and scatters the results to some memory area for later processing (or retrieving).

More modern stream processing frameworks provide a FIFO like interface to structure data as a literal stream. This abstraction

provides a means to specify data dependencies implicitly while enabling the runtime/hardware to take full advantage of that

knowledge for efficient computation. One of the simplest and most efficient stream processing modalities to date for C++,

is <a href="RaftLib" title="RaftLib">RaftLib</a>, which enables linking independent <a href="Compute_kernel" title="Compute kernel">compute kernels</a> together as a data flow graph using C++ stream operators. As an example:

<div class="mw-highlight mw-highlight-lang-cpp mw-content-ltr" dir="ltr"><pre>#include <raft>

#include <raftio>

#include <cstdlib>

#include <string>

class hi : public raft::kernel

{

public:

hi() : raft::kernel()

{

output.addPort<std::string>("0");

}

virtual raft::kstatus run()

{

output["0"].push(std::string("Hello World\n"));

return raft::stop;

}

};

int main(int argc, char **argv)

{

/** instantiate print kernel **/

raft::print< std::string > p;

/** instantiate hello world kernel **/

hi hello;

/** make a map object **/

raft::map m;

/** add kernels to map, both hello and p are executed concurrently **/

m += hello >> p;

/** execute the map **/

m.exe();

return EXIT_SUCCESS;

}

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="Models_of_computation_for_stream_processing">Models of computation for stream processing</h3></div>

Apart from specifying streaming applications in high-level languages, models of computation (MoCs) also have been widely used as <a href="Dataflow" title="Dataflow">dataflow</a> models and process-based models.

<div class="mw-heading mw-heading3"><h3 id="Generic_processor_architecture">Generic processor architecture</h3></div>

Historically, CPUs began implementing various tiers of memory access optimizations because of the ever-increasing performance when compared to relatively slow growing external memory bandwidth. As this gap widened, big amounts of die area were dedicated to hiding memory latencies. Since fetching information and opcodes to those few ALUs is expensive, very little die area is dedicated to actual mathematical machinery (as a rough estimation, consider it to be less than 10%).

A similar architecture exists on stream processors but thanks to the new programming model, the amount of transistors dedicated to management is actually very little.

Beginning from a whole system point of view, stream processors usually exist in a controlled environment. GPUs do exist on an add-in board (this seems to also apply to Imagine). CPUs continue do the job of managing system resources, running applications, and such.

The stream processor is usually equipped with a fast, efficient, proprietary memory bus (crossbar switches are now common, multi-buses have been employed in the past). The exact amount of memory lanes is dependent on the market range. As this is written, there are still 64-bit wide interconnections around (entry-level). Most mid-range models use a fast 128-bit crossbar switch matrix (4 or 2 segments), while high-end models deploy huge amounts of memory (actually up to 512 MB) with a slightly slower crossbar that is 256 bits wide. By contrast, standard processors from <a href="Intel_Pentium" class="mw-redirect" title="Intel Pentium">Intel Pentium</a> to some <a href="Athlon_64" title="Athlon 64">Athlon 64</a> have only a single 64-bit wide data bus.

Memory access patterns are much more predictable. While arrays do exist, their dimension is fixed at kernel invocation. The thing which most closely matches a multiple pointer indirection is an indirection chain, which is however guaranteed to finally read or write from a specific memory area (inside a stream).

Because of the SIMD nature of the stream processor's execution units (ALUs clusters), read/write operations are expected to happen in bulk, so memories are optimized for high bandwidth rather than low latency (this is a difference from <a href="Rambus" title="Rambus">Rambus</a> and <a href="DDR_SDRAM" title="DDR SDRAM">DDR SDRAM</a>, for example). This also allows for efficient memory bus negotiations.

Most (90%) of a stream processor's work is done on-chip, requiring only 1% of the global data to be stored to memory. This is where knowing the kernel temporaries and dependencies pays.

Internally, a stream processor features some clever communication and management circuits but what's interesting is the Stream Register File (SRF). This is conceptually a large cache in which stream data is stored to be transferred to external memory in bulks. As a cache-like software-controlled structure to the various <a href="Arithmetic_logic_unit" title="Arithmetic logic unit">ALUs</a>, the SRF is shared between all the various ALU clusters. The key concept and innovation here done with Stanford's Imagine chip is that the compiler is able to automate and allocate memory in an optimal way, fully transparent to the programmer. The dependencies between kernel functions and data is known through the programming model which enables the compiler to perform flow analysis and optimally pack the SRFs. Commonly, this cache and DMA management can take up the majority of a project's schedule, something the stream processor (or at least Imagine) totally automates. Tests done at Stanford showed that the compiler did an as well or better job at scheduling memory than if you hand tuned the thing with much effort.

There is proof; there can be a lot of clusters because inter-cluster communication is assumed to be rare. Internally however, each cluster can efficiently exploit a much lower amount of ALUs because intra-cluster communication is common and thus needs to be highly efficient.

To keep those ALUs fetched with data, each ALU is equipped with local register files (LRFs), which are basically its usable registers.

This three-tiered data access pattern, makes it easy to keep temporary data away from slow memories, thus making the silicon implementation highly efficient and power-saving.

<div class="mw-heading mw-heading3"><h3 id="Hardware-in-the-loop_issues">Hardware-in-the-loop issues</h3></div>

Although an order of magnitude speedup can be reasonably expected (even from mainstream GPUs when computing in a streaming manner), not all applications benefit from this. Communication latencies are actually the biggest problem. Although <a href="PCI_Express" title="PCI Express">PCI Express</a> improved this with full-duplex communications, getting a GPU (and possibly a generic stream processor) to work will possibly take long amounts of time. This means it's usually counter-productive to use them for small datasets. Because changing the kernel is a rather expensive operation the stream architecture also incurs penalties for small streams, a behaviour referred to as the short stream effect.

<a href="Instruction_pipeline" class="mw-redirect" title="Instruction pipeline">Pipelining</a> is a very widespread and heavily used practice on stream processors, with GPUs featuring pipelines exceeding 200 stages. The cost for switching settings is dependent on the setting being modified but it is now considered to always be expensive. To avoid those problems at various levels of the pipeline, many techniques have been deployed such as "über shaders" and "texture atlases". Those techniques are game-oriented because of the nature of GPUs, but the concepts are interesting for generic stream processing as well.

<div class="mw-heading mw-heading2"><h2 id="Examples">Examples</h2></div>

<ul><li>The <a href="Blitter" title="Blitter">Blitter</a> in the Commodore <a href="Amiga" title="Amiga">Amiga</a> is an early (circa 1985) graphics processor capable of combining three source streams of 16 component bit vectors in 256 ways to produce an output stream consisting of 16 component bit vectors. Total input stream bandwidth is up to 42 million bits per second. Output stream bandwidth is up to 28 million bits per second.</li>

<li>Imagine,<a href="#cite_note-10">[10]</a> headed by Professor <a href="Bill_Dally" title="Bill Dally">William Dally</a> of <a href="Stanford_University" title="Stanford University">Stanford University</a>, is a flexible architecture intended to be both fast and energy efficient. The project, originally conceived in 1996, included architecture, software tools, a VLSI implementation and a development board, was funded by <a href="DARPA" title="DARPA">DARPA</a>, <a href="Intel" title="Intel">Intel</a> and <a href="Texas_Instruments" title="Texas Instruments">Texas Instruments</a>.</li>

<li>Another <a href="Stanford" class="mw-redirect" title="Stanford">Stanford</a> project, called Merrimac,<a href="#cite_note-11">[11]</a> is aimed at developing a stream-based supercomputer. Merrimac intends to use a stream architecture and advanced interconnection networks to provide more performance per unit cost than cluster-based scientific computers built from the same technology.</li>

<li>The Storm-1 family from <a href="Stream_Processors%2C_Inc" class="mw-redirect" title="Stream Processors, Inc">Stream Processors, Inc</a>, a commercial spin-off of Stanford's Imagine project, was announced during a feature presentation at <a href="ISSCC" class="mw-redirect" title="ISSCC">ISSCC</a> 2007. The family contains four members ranging from 30 GOPS to 220 16-bit GOPS (billions of operations per second), all fabricated at <a href="TSMC" title="TSMC">TSMC</a> in a 130 nanometer process. The devices target the high end of the <a href="Digital_signal_processor" title="Digital signal processor">DSP</a> market including <a href="Video_conferencing" class="mw-redirect" title="Video conferencing">video conferencing</a>, <a href="Multifunction_printer" class="mw-redirect" title="Multifunction printer">multifunction printers</a> and digital <a href="Video_surveillance" class="mw-redirect" title="Video surveillance">video surveillance</a> equipment.</li>

<li><a href="GPU" class="mw-redirect" title="GPU">GPUs</a> are widespread, consumer-grade stream processors<a class="external autonumber external" href="https://en.wikipedia.org/wiki/Stream_processing#endnote_GPUasSTREAM">[2]</a> designed mainly by <a href="AMD" title="AMD">AMD</a> and <a href="Nvidia" title="Nvidia">Nvidia</a>. Various generations to be noted from a stream processing point of view:

<ul><li>Pre-R2xx/NV2x: no explicit support for stream processing. Kernel operations were hidden in the <a href="API" title="API">API</a> and provided too little flexibility for general use.</li>

<li>R2xx/NV2x: kernel stream operations became explicitly under the programmer's control but only for vertex processing (fragments were still using old paradigms). No branching support severely hampered flexibility but some types of algorithms could be run (notably, low-precision fluid simulation).</li>

<li>R3xx/NV4x: flexible branching support although some limitations still exist on the number of operations to be executed and strict recursion depth, as well as array manipulation.</li>

<li>R8xx: Supports append/consume buffers and atomic operations. This generation is the state of the art.</li></ul></li>

<li><a href="AMD_FireStream" title="AMD FireStream">AMD FireStream</a> brand name for product line targeting HPC</li>

<li><a href="Nvidia_Tesla" title="Nvidia Tesla">Nvidia Tesla</a> brand name for product line targeting HPC</li>

<li>The <a href="Cell_processor" class="mw-redirect" title="Cell processor">Cell processor</a> from STI, an alliance of <a href="Sony_Computer_Entertainment" class="mw-redirect" title="Sony Computer Entertainment">Sony Computer Entertainment</a>, <a href="Toshiba_Corporation" class="mw-redirect" title="Toshiba Corporation">Toshiba Corporation</a>, and <a href="IBM" title="IBM">IBM</a>, is a hardware architecture that can function like a stream processor with appropriate software support. It consists of a controlling processor, the PPE (Power Processing Element, an IBM <a href="PowerPC" title="PowerPC">PowerPC</a>) and a set of SIMD coprocessors, called SPEs (Synergistic Processing Elements), each with independent program counters and instruction memory, in effect a <a href="Multiple_instruction%2C_multiple_data" title="Multiple instruction, multiple data">MIMD</a> machine. In the native programming model all DMA and program scheduling is left up to the programmer. The hardware provides a fast ring bus among the processors for local communication. Because the local memory for instructions and data is limited the only programs that can exploit this architecture effectively either require a tiny <a href="Memory_footprint" title="Memory footprint">memory footprint</a> or adhere to a stream programming model. With a suitable algorithm the performance of the Cell can rival that of pure stream processors, however this nearly always requires a complete redesign of algorithms and software.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Stream_programming_libraries_and_languages">Stream programming libraries and languages</h2></div>

Most programming languages for stream processors start with Java, C or C++ and add extensions which provide specific instructions to allow application developers to tag kernels and/or streams. This also applies to most <a href="Shading_language" title="Shading language">shading languages</a>, which can be considered stream programming languages to a certain degree.

Non-commercial examples of stream programming languages include:

<ul><li><a href="Ateji_PX" title="Ateji PX">Ateji PX</a> Free Edition, enables a simple expression of stream programming, the actor model, and the MapReduce algorithm on <a href="JVM" class="mw-redirect" title="JVM">JVM</a></li>

<li>Auto-Pipe, from the Stream Based Supercomputing Lab at <a href="Washington_University_in_St._Louis" title="Washington University in St. Louis">Washington University in St. Louis</a>, an application development environment for streaming applications that allows authoring of applications for heterogeneous systems (CPU, <a href="GPGPU" class="mw-redirect" title="GPGPU">GPGPU</a>, FPGA). Applications can be developed in any combination of C, C++, and Java for the CPU. Verilog or VHDL for FPGAs. Cuda is currently used for Nvidia GPGPUs. Auto-Pipe also handles coordination of TCP connections between multiple machines.</li>

<li>ACOTES programming model: language from <a href="Polytechnic_University_of_Catalonia" title="Polytechnic University of Catalonia">Polytechnic University of Catalonia</a> based on <a href="OpenMP" title="OpenMP">OpenMP</a></li>

<li>BeepBeep, a simple and lightweight Java-based event stream processing library from the Formal Computer Science Lab at <a href="UQAC" class="mw-redirect" title="UQAC">Université du Québec à Chicoutimi</a></li>

<li>Brook language from <a href="Stanford" class="mw-redirect" title="Stanford">Stanford</a></li>

<li><a href="CAL_Actor_Language" title="CAL Actor Language">CAL Actor Language</a>: a high-level programming language for writing (dataflow) actors, which are stateful operators that transform input streams of data objects (tokens) into output streams.</li>

<li>Cal2Many a code generation framework from Halmstad University, Sweden. It takes CAL code as input and generates different target specific languages including sequential C, Chisel, parallel C targeting Epiphany architecture, ajava & astruct targeting Ambric architecture, etc..</li>

<li>DUP language from <a href="Technical_University_of_Munich" title="Technical University of Munich">Technical University of Munich</a> and <a href="University_of_Denver" title="University of Denver">University of Denver</a></li>

<li>HSTREAM: a directive-based language extension for heterogeneous stream computing<a href="#cite_note-12">[12]</a></li>

<li>RaftLib - open source C++ stream processing template library originally from the Stream Based Supercomputing Lab at <a href="Washington_University_in_St._Louis" title="Washington University in St. Louis">Washington University in St. Louis</a></li>

<li><a rel="nofollow" class="external text" href="https://github.com/reactivehtml/rimmel">Rimmel.js</a> a JavaScript library enabling streams-based UI development by treating all HTML nodes and attributes as reactive sources and sinks)</li>

<li>SPar - C++ domain-specific language for expressing stream parallelism from the Application Modelling Group (GMAP) at <a href="Pontifical_Catholic_University_of_Rio_Grande_do_Sul" title="Pontifical Catholic University of Rio Grande do Sul">Pontifical Catholic University of Rio Grande do Sul</a></li>

<li><a href="Lib_Sh" title="Lib Sh">Sh</a> library from the <a href="University_of_Waterloo" title="University of Waterloo">University of Waterloo</a></li>

<li>Shallows, an open source project</li>

<li>S-Net coordination language from the <a href="University_of_Hertfordshire" title="University of Hertfordshire">University of Hertfordshire</a>, which provides separation of coordination and algorithmic programming</li>

<li>StreamIt from <a href="MIT" class="mw-redirect" title="MIT">MIT</a></li>

<li>Siddhi from <a href="WSO2" title="WSO2">WSO2</a></li>

<li>WaveScript functional stream processing, also from MIT.</li>

<li><a href="Functional_reactive_programming" title="Functional reactive programming">Functional reactive programming</a> could be considered stream processing in a broad sense.</li></ul>

Commercial implementations are either general purpose or tied to specific hardware by a vendor. Examples of general purpose languages include:

<ul><li><a href="AccelerEyes" class="mw-redirect" title="AccelerEyes">AccelerEyes</a>' Jacket, a commercialization of a GPU engine for MATLAB</li>

<li><a href="Ateji_PX" title="Ateji PX">Ateji PX</a> Java extension that enables a simple expression of stream programming, the Actor model, and the MapReduce algorithm</li>

<li>Embiot, a lightweight embedded streaming analytics agent from Telchemy</li>

<li>Floodgate, a stream processor provided with the <a href="Gamebryo" title="Gamebryo">Gamebryo</a> game engine for PlayStation 3, Xbox360, Wii, and PC</li>

<li><a href="OpenHMPP" title="OpenHMPP">OpenHMPP</a>, a "directive" vision of Many-Core programming</li>

<li>PeakStream,<a href="#cite_note-13">[13]</a> a spinout of the <a href="BrookGPU" title="BrookGPU">Brook</a> project (acquired by <a href="List_of_Google_acquisitions" class="mw-redirect" title="List of Google acquisitions">Google</a> in June 2007)</li>

<li>IBM Spade - Stream Processing Application Declarative Engine (B. Gedik, et al. SPADE: the system S declarative stream processing engine. ACM SIGMOD 2008.)</li>

<li><a href="RapidMind" title="RapidMind">RapidMind</a>, a commercialization of <a href="Lib_Sh" title="Lib Sh">Sh</a> (acquired by <a href="Intel" title="Intel">Intel</a> in August 2009)</li>

<li>TStreams,<a href="#cite_note-14">[14]</a><a href="#cite_note-15">[15]</a> Hewlett-Packard Cambridge Research Lab</li></ul>

Vendor-specific languages include:

<ul><li>Brook+ (AMD hardware optimized implementation of <a href="BrookGPU" title="BrookGPU">Brook</a>) from <a href="AMD" title="AMD">AMD</a>/<a href="ATI_Technologies" title="ATI Technologies">ATI</a></li>

<li><a href="CUDA" title="CUDA">CUDA</a> (Compute Unified Device Architecture) from <a href="Nvidia" title="Nvidia">Nvidia</a></li>

<li><a href="Intel_Ct" title="Intel Ct">Intel Ct</a> - C for <a href="High-throughput_computing" title="High-throughput computing">Throughput Computing</a></li>

<li>StreamC from <a href="Stream_Processors%2C_Inc" class="mw-redirect" title="Stream Processors, Inc">Stream Processors, Inc</a>, a commercialization of the Imagine work at Stanford</li></ul>

Event-Based Processing

<ul><li><a href="Apama_(software)" title="Apama (software)">Apama</a> - a combined <a href="Complex_event_processing" title="Complex event processing">complex event</a> and <a href="Stream_Processing" class="mw-redirect" title="Stream Processing">stream processing</a> engine by <a href="Software_AG" title="Software AG">Software AG</a></li>

<li>Wallaroo</li>

<li>WSO2 stream processor by <a href="WSO2" title="WSO2">WSO2</a></li>

<li><a href="Apache_NiFi" title="Apache NiFi">Apache NiFi</a></li></ul>

Batch file-based processing (emulates some of actual stream processing, but much lower performance in general)

<ul><li><a href="Apache_Kafka" title="Apache Kafka">Apache Kafka</a></li>

<li><a href="Apache_Storm" title="Apache Storm">Apache Storm</a></li>

<li><a href="Apache_Apex" title="Apache Apex">Apache Apex</a></li>

<li><a href="Apache_Spark" title="Apache Spark">Apache Spark</a></li></ul>

Continuous operator stream processing

<ul><li><a href="Apache_Flink" title="Apache Flink">Apache Flink</a></li>

<li>Walmartlabs Mupd8<a href="#cite_note-16">[16]</a></li>

<li>Eclipse Streamsheets - spreadsheet for stream processing</li></ul>

Stream processing services:

<ul><li>Amazon Web Services - Kinesis</li>

<li>Google Cloud - Dataflow</li>

<li>Microsoft Azure - Stream analytics</li>

<li>Datastreams - Data streaming analytics platform</li>

<li>IBM streams

<ul><li>IBM streaming analytics</li></ul></li>

<li>Eventador SQLStreamBuilder</li></ul>

/* start https://en.wikipedia.org/ */

.mw-parser-output .div-col{margin-top:0.3em;column-width:30em}.mw-parser-output .div-col-small{font-size:90%}.mw-parser-output .div-col-rules{column-rule:1px solid #aaa}.mw-parser-output .div-col dl,.mw-parser-output .div-col ol,.mw-parser-output .div-col ul{margin-top:0}.mw-parser-output .div-col li,.mw-parser-output .div-col dd{page-break-inside:avoid;break-inside:avoid-column}

/* end https://en.wikipedia.org/ */

</style><div class="div-col" style="column-width: 20em;">

<ul><li><a href="Data_stream_mining" title="Data stream mining">Data stream mining</a></li>

<li><a href="Data_Stream_Management_System" class="mw-redirect" title="Data Stream Management System">Data Stream Management System</a></li>

<li><a href="Dimension_reduction" class="mw-redirect" title="Dimension reduction">Dimension reduction</a></li>

<li><a href="Flow-based_programming" title="Flow-based programming">Flow-based programming</a></li>

<li><a href="Hardware_acceleration" title="Hardware acceleration">Hardware acceleration</a></li>

<li><a href="Molecular_modeling_on_GPU" class="mw-redirect" title="Molecular modeling on GPU">Molecular modeling on GPU</a></li>

<li><a href="Parallel_computing" title="Parallel computing">Parallel computing</a></li>

<li><a href="Partitioned_global_address_space" title="Partitioned global address space">Partitioned global address space</a></li>

<li><a href="Real-time_computing" title="Real-time computing">Real-time computing</a></li>

<li><a href="Real_Time_Streaming_Protocol" class="mw-redirect" title="Real Time Streaming Protocol">Real Time Streaming Protocol</a></li>

<li><a href="Streaming_algorithm" title="Streaming algorithm">Streaming algorithm</a></li>

<li><a href="Vector_processor" title="Vector processor">Vector processor</a></li></ul></div>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist reflist-columns references-column-width" style="column-width: 30em;">

<li id="cite_note-1"><a href="#cite_ref-1">^</a> <a rel="nofollow" class="external text" href="https://www.jonathanbeard.io/blog/2015/09/19/streaming-and-dataflow.html">A SHORT INTRO TO STREAM PROCESSING</a>

</li>

<li id="cite_note-2"><a href="#cite_ref-2">^</a> <a rel="nofollow" class="external text" href="http://impact.crhc.illinois.edu/shared/papers/fcuda2009.pdf">FCUDA: Enabling Efficient Compilation of CUDA Kernels onto FPGAs</a>

</li>

<li id="cite_note-3"><a href="#cite_ref-3">^</a> IEEE Journal of Solid-State Circuits:<a rel="nofollow" class="external text" href="https://ieeexplore.ieee.org/document/4443192/;jsessionid=0F8BC0D153AF18E47A29359358253544?arnumber=4443192">"A Programmable 512 GOPS Stream Processor for Signal, Image, and Video Processing"</a>, Stanford University and Stream Processors, Inc.

</li>

<li id="cite_note-4"><a href="#cite_ref-4">^</a> Khailany, Dally, Rixner, Kapasi, Owens and Towles: <a rel="nofollow" class="external text" href="http://cva.stanford.edu/publications/2003/khailany_im_scalability.pdf">"Exploring VLSI Scalability of Stream Processors"</a>, Stanford and Rice University.

</li>

<li id="cite_note-5"><a href="#cite_ref-5">^</a> Gummaraju and Rosenblum, <a rel="nofollow" class="external text" href="http://www.cs.utexas.edu/users/skeckler/wild04/Paper14.pdf">"Stream processing in General-Purpose Processors"</a>, Stanford University.

</li>

<li id="cite_note-6"><a href="#cite_ref-6">^</a> Kapasi, Dally, Rixner, Khailany, Owens, Ahn and Mattson, <a rel="nofollow" class="external text" href="http://cva.stanford.edu/publications/2003/ieeecomputer_stream.pdf">"Programmable Stream Processors"</a>, Universities of Stanford, Rice, California (Davis) and Reservoir Labs.

</li>

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFEric_Chan" class="citation web cs1">Eric Chan. <a rel="nofollow" class="external text" href="http://graphics.stanford.edu/projects/shading/">"Stanford Real-Time Programmable Shading Project"</a>. Research group web site. Retrieved March 9, 2017.</cite>

</li>

<li id="cite_note-8"><a href="#cite_ref-8">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://cva.stanford.edu/projects/imagine/">"The Imagine - Image and Signal Processor"</a>. Group web site. Retrieved March 9, 2017.</cite>

</li>

<li id="cite_note-9"><a href="#cite_ref-9">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20131218194055/http://merrimac.stanford.edu/">"Merrimac - Stanford Streaming Supercomputer Project"</a>. Group web site. Archived from <a rel="nofollow" class="external text" href="http://merrimac.stanford.edu/">the original</a> on December 18, 2013. Retrieved March 9, 2017.</cite>

</li>

<li id="cite_note-10"><a href="#cite_ref-10">^</a> <a rel="nofollow" class="external text" href="http://cva.stanford.edu/projects/imagine/">Imagine</a>

</li>

<li id="cite_note-11"><a href="#cite_ref-11">^</a> <a rel="nofollow" class="external text" href="http://merrimac.stanford.edu/">Merrimac</a>

</li>

<li id="cite_note-12"><a href="#cite_ref-12">^</a> <cite id="CITEREFMemetiPllana2018" class="citation conference cs1">Memeti, Suejb; Pllana, Sabri (October 2018). "HSTREAM: A Directive-Based Language Extension for Heterogeneous Stream Computing". 2018 IEEE International Conference on Computational Science and Engineering (CSE). IEEE. pp. 138–145. <a href="ArXiv_(identifier)" class="mw-redirect" title="ArXiv (identifier)">arXiv</a>:<a rel="nofollow" class="external text" href="https://arxiv.org/abs/1809.09387">1809.09387</a>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2FCSE.2018.00026">10.1109/CSE.2018.00026</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-1-5386-7649-3</bdi>.</cite>

</li>

<li id="cite_note-13"><a href="#cite_ref-13">^</a> <a rel="nofollow" class="external text" href="https://arstechnica.com/news.ars/post/20060918-7763.html">PeakStream unveils multicore and CPU/GPU programming solution</a>

</li>

<li id="cite_note-14"><a href="#cite_ref-14">^</a> <cite class="citation techreport cs1"><a rel="nofollow" class="external text" href="http://www.hpl.hp.com/techreports/2004/HPL-2004-78R1.html">TStreams: A Model of Parallel Computation</a> (Technical report).</cite>

</li>

<li id="cite_note-15"><a href="#cite_ref-15">^</a> <cite class="citation techreport cs1"><a rel="nofollow" class="external text" href="http://www.hpl.hp.com/techreports/2004/HPL-2004-193.html">TStreams: How to Write a Parallel Program</a> (Technical report).</cite>

</li>

<li id="cite_note-16"><a href="#cite_ref-16">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://github.com/walmartlabs/mupd8">"GitHub - walmartlabs/Mupd8: Muppet"</a>. <a href="GitHub" title="GitHub">GitHub</a>.</cite>

</li>

</ol></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hlist dl,.mw-parser-output .hlist ol,.mw-parser-output .hlist ul{margin:0;padding:0}.mw-parser-output .hlist dd,.mw-parser-output .hlist dt,.mw-parser-output .hlist li{margin:0;display:inline}.mw-parser-output .hlist.inline,.mw-parser-output .hlist.inline dl,.mw-parser-output .hlist.inline ol,.mw-parser-output .hlist.inline ul,.mw-parser-output .hlist dl dl,.mw-parser-output .hlist dl ol,.mw-parser-output .hlist dl ul,.mw-parser-output .hlist ol dl,.mw-parser-output .hlist ol ol,.mw-parser-output .hlist ol ul,.mw-parser-output .hlist ul dl,.mw-parser-output .hlist ul ol,.mw-parser-output .hlist ul ul{display:inline}.mw-parser-output .hlist .mw-empty-li{display:none}.mw-parser-output .hlist dt::after{content:": "}.mw-parser-output .hlist dd::after,.mw-parser-output .hlist li::after{content:" · ";font-weight:bold}.mw-parser-output .hlist dd:last-child::after,.mw-parser-output .hlist dt:last-child::after,.mw-parser-output .hlist li:last-child::after{content:none}.mw-parser-output .hlist dd dd:first-child::before,.mw-parser-output .hlist dd dt:first-child::before,.mw-parser-output .hlist dd li:first-child::before,.mw-parser-output .hlist dt dd:first-child::before,.mw-parser-output .hlist dt dt:first-child::before,.mw-parser-output .hlist dt li:first-child::before,.mw-parser-output .hlist li dd:first-child::before,.mw-parser-output .hlist li dt:first-child::before,.mw-parser-output .hlist li li:first-child::before{content:" (";font-weight:normal}.mw-parser-output .hlist dd dd:last-child::after,.mw-parser-output .hlist dd dt:last-child::after,.mw-parser-output .hlist dd li:last-child::after,.mw-parser-output .hlist dt dd:last-child::after,.mw-parser-output .hlist dt dt:last-child::after,.mw-parser-output .hlist dt li:last-child::after,.mw-parser-output .hlist li dd:last-child::after,.mw-parser-output .hlist li dt:last-child::after,.mw-parser-output .hlist li li:last-child::after{content:")";font-weight:normal}.mw-parser-output .hlist ol{counter-reset:listitem}.mw-parser-output .hlist ol>li{counter-increment:listitem}.mw-parser-output .hlist ol>li::before{content:" "counter(listitem)"\a0 "}.mw-parser-output .hlist dd ol>li:first-child::before,.mw-parser-output .hlist dt ol>li:first-child::before,.mw-parser-output .hlist li ol>li:first-child::before{content:" ("counter(listitem)"\a0 "}

/* end https://en.wikipedia.org/ */

</style><style data-mw-deduplicate="TemplateStyles:r1236075235">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbox{box-sizing:border-box;border:1px solid #a2a9b1;width:100%;clear:both;font-size:88%;text-align:center;padding:1px;margin:1em auto 0}.mw-parser-output .navbox .navbox{margin-top:0}.mw-parser-output .navbox+.navbox,.mw-parser-output .navbox+.navbox-styles+.navbox{margin-top:-1px}.mw-parser-output .navbox-inner,.mw-parser-output .navbox-subgroup{width:100%}.mw-parser-output .navbox-group,.mw-parser-output .navbox-title,.mw-parser-output .navbox-abovebelow{padding:0.25em 1em;line-height:1.5em;text-align:center}.mw-parser-output .navbox-group{white-space:nowrap;text-align:right}.mw-parser-output .navbox,.mw-parser-output .navbox-subgroup{background-color:#fdfdfd}.mw-parser-output .navbox-list{line-height:1.5em;border-color:#fdfdfd}.mw-parser-output .navbox-list-with-group{text-align:left;border-left-width:2px;border-left-style:solid}.mw-parser-output tr+tr>.navbox-abovebelow,.mw-parser-output tr+tr>.navbox-group,.mw-parser-output tr+tr>.navbox-image,.mw-parser-output tr+tr>.navbox-list{border-top:2px solid #fdfdfd}.mw-parser-output .navbox-title{background-color:#ccf}.mw-parser-output .navbox-abovebelow,.mw-parser-output .navbox-group,.mw-parser-output .navbox-subgroup .navbox-title{background-color:#ddf}.mw-parser-output .navbox-subgroup .navbox-group,.mw-parser-output .navbox-subgroup .navbox-abovebelow{background-color:#e6e6ff}.mw-parser-output .navbox-even{background-color:#f7f7f7}.mw-parser-output .navbox-odd{background-color:transparent}.mw-parser-output .navbox .hlist td dl,.mw-parser-output .navbox .hlist td ol,.mw-parser-output .navbox .hlist td ul,.mw-parser-output .navbox td.hlist dl,.mw-parser-output .navbox td.hlist ol,.mw-parser-output .navbox td.hlist ul{padding:0.125em 0}.mw-parser-output .navbox .navbar{display:block;font-size:100%}.mw-parser-output .navbox-title .navbar{float:left;text-align:left;margin-right:0.5em}body.skin--responsive .mw-parser-output .navbox-image img{max-width:none!important}@media print{body.ns-0 .mw-parser-output .navbox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style></div><div role="navigation" class="navbox" aria-labelledby="Parallel_computing346" style="padding:3px"><table class="nowraplinks hlist mw-collapsible autocollapse navbox-inner" style="border-spacing:0;background:transparent;color:inherit"><tbody><tr><th scope="col" class="navbox-title" colspan="2"><style data-mw-deduplicate="TemplateStyles:r1239400231">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbar{display:inline;font-size:88%;font-weight:normal}.mw-parser-output .navbar-collapse{float:left;text-align:left}.mw-parser-output .navbar-boxtext{word-spacing:0}.mw-parser-output .navbar ul{display:inline-block;white-space:nowrap;line-height:inherit}.mw-parser-output .navbar-brackets::before{margin-right:-0.125em;content:"[ "}.mw-parser-output .navbar-brackets::after{margin-left:-0.125em;content:" ]"}.mw-parser-output .navbar li{word-spacing:-0.125em}.mw-parser-output .navbar a>span,.mw-parser-output .navbar a>abbr{text-decoration:inherit}.mw-parser-output .navbar-mini abbr{font-variant:small-caps;border-bottom:none;text-decoration:none;cursor:inherit}.mw-parser-output .navbar-ct-full{font-size:114%;margin:0 7em}.mw-parser-output .navbar-ct-mini{font-size:114%;margin:0 4em}html.skin-theme-clientpref-night .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}@media(prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}}@media print{.mw-parser-output .navbar{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div id="Parallel_computing346" style="font-size:114%;margin:0 4em"><a href="Parallel_computing" title="Parallel computing">Parallel computing</a></div></th></tr><tr><th scope="row" class="navbox-group" style="width:1%">General</th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Distributed_computing" title="Distributed computing">Distributed computing</a></li>

<li><a href="Parallel_computing" title="Parallel computing">Parallel computing</a></li>

<li><a href="Parallel_algorithm" title="Parallel algorithm">Parallel algorithm</a></li>

<li><a href="Massively_parallel" title="Massively parallel">Massively parallel</a></li>

<li><a href="Cloud_computing" title="Cloud computing">Cloud computing</a></li>

<li><a href="High-performance_computing" title="High-performance computing">High-performance computing</a></li>

<li><a href="Multiprocessing" title="Multiprocessing">Multiprocessing</a></li>

<li><a href="Manycore_processor" title="Manycore processor">Manycore processor</a></li>

<li><a href="General-purpose_computing_on_graphics_processing_units" title="General-purpose computing on graphics processing units">GPGPU</a></li>

<li><a href="Computer_network" title="Computer network">Computer network</a></li>

<li><a href="Systolic_array" title="Systolic array">Systolic array</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Levels</th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<li><a href="Instruction-level_parallelism" title="Instruction-level parallelism">Instruction</a></li>

<li><a href="Task_parallelism" title="Task parallelism">Thread</a></li>

<li><a href="Memory-level_parallelism" title="Memory-level parallelism">Memory</a></li>

<li><a href="Pipeline_(computing)" title="Pipeline (computing)">Pipeline</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Multithreading_(computer_architecture)" title="Multithreading (computer architecture)">Multithreading</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Temporal_multithreading" title="Temporal multithreading">Temporal</a></li>

<li><a href="Simultaneous_multithreading" title="Simultaneous multithreading">Simultaneous</a> (SMT)</li>

<li><a href="Simultaneous_and_heterogeneous_multithreading" title="Simultaneous and heterogeneous multithreading">Simultaneous and heterogenous</a></li>

<li><a href="Speculative_multithreading" title="Speculative multithreading">Speculative</a> (SpMT)</li>

<li><a href="Preemption_(computing)" title="Preemption (computing)">Preemptive</a></li>

<li><a href="Computer_multitasking#Cooperative_multitasking" title="Computer multitasking">Cooperative</a></li>

<li><a href="Bulldozer_(microarchitecture)#Bulldozer_core" title="Bulldozer (microarchitecture)">Clustered multi-thread</a> (CMT)</li>

<li><a href="Hardware_scout" title="Hardware scout">Hardware scout</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Theory</th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Parallel_RAM" title="Parallel RAM">PRAM model</a></li>

<li><a href="Parallel_external_memory" title="Parallel external memory">PEM model</a></li>

<li><a href="Analysis_of_parallel_algorithms" title="Analysis of parallel algorithms">Analysis of parallel algorithms</a></li>

<li><a href="Amdahl's_law" title="Amdahl's law">Amdahl's law</a></li>

<li><a href="Gustafson's_law" title="Gustafson's law">Gustafson's law</a></li>

<li><a href="Cost_efficiency" title="Cost efficiency">Cost efficiency</a></li>

<li><a href="Karp%E2%80%93Flatt_metric" title="Karp–Flatt metric">Karp–Flatt metric</a></li>

<li><a href="Parallel_slowdown" title="Parallel slowdown">Slowdown</a></li>

<li><a href="Speedup" title="Speedup">Speedup</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Elements</th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Process_(computing)" title="Process (computing)">Process</a></li>

<li><a href="Thread_(computing)" title="Thread (computing)">Thread</a></li>

<li><a href="Fiber_(computer_science)" title="Fiber (computer science)">Fiber</a></li>

<li><a href="Instruction_window" title="Instruction window">Instruction window</a></li>

<li><a href="Array_(data_structure)" title="Array (data structure)">Array</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Coordination</th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Multiprocessing" title="Multiprocessing">Multiprocessing</a></li>

<li><a href="Memory_coherence" title="Memory coherence">Memory coherence</a></li>

<li><a href="Cache_coherence" title="Cache coherence">Cache coherence</a></li>

<li><a href="Cache_invalidation" title="Cache invalidation">Cache invalidation</a></li>

<li><a href="Barrier_(computer_science)" title="Barrier (computer science)">Barrier</a></li>

<li><a href="Synchronization_(computer_science)" title="Synchronization (computer science)">Synchronization</a></li>

<li><a href="Application_checkpointing" title="Application checkpointing">Application checkpointing</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Computer_programming" title="Computer programming">Programming</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul>

<li><a href="Dataflow_programming" title="Dataflow programming">Dataflow programming</a></li>

<li><a href="Parallel_programming_model" title="Parallel programming model">Models</a>

<ul><li><a href="Implicit_parallelism" title="Implicit parallelism">Implicit parallelism</a></li>

<li><a href="Explicit_parallelism" title="Explicit parallelism">Explicit parallelism</a></li>

<li><a href="Concurrency_(computer_science)" title="Concurrency (computer science)">Concurrency</a></li></ul></li>

<li><a href="Non-blocking_algorithm" title="Non-blocking algorithm">Non-blocking algorithm</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Computer_hardware" title="Computer hardware">Hardware</a></th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Flynn's_taxonomy" title="Flynn's taxonomy">Flynn's taxonomy</a>

<ul><li><a href="Single_instruction%2C_multiple_threads" title="Single instruction, multiple threads">Array processing</a> (SIMT)</li>

<li><a href="Flynn's_taxonomy#Pipelined_processor" title="Flynn's taxonomy">Pipelined processing</a></li>

<li><a href="Flynn's_taxonomy#Associative_processor" title="Flynn's taxonomy">Associative processing</a></li></ul></li>

<li><a href="Dataflow_architecture" title="Dataflow architecture">Dataflow architecture</a></li>

<li><a href="Instruction_pipelining" title="Instruction pipelining">Pipelined processor</a></li>

<li><a href="Superscalar_processor" title="Superscalar processor">Superscalar processor</a></li>

<li><a href="Vector_processor" title="Vector processor">Vector processor</a></li>

<li><a href="Multiprocessing" title="Multiprocessing">Multiprocessor</a>

<ul><li><a href="Symmetric_multiprocessing" title="Symmetric multiprocessing">symmetric</a></li>

<li><a href="Asymmetric_multiprocessing" title="Asymmetric multiprocessing">asymmetric</a></li></ul></li>

<li><a href="Semiconductor_memory" title="Semiconductor memory">Memory</a>

<ul><li><a href="Shared_memory" title="Shared memory">shared</a></li>

<li><a href="Distributed_memory" title="Distributed memory">distributed</a></li>

<li><a href="Distributed_shared_memory" title="Distributed shared memory">distributed shared</a></li>

<li><a href="Massively_parallel" title="Massively parallel">Massively parallel</a> computer</li>

<li><a href="Computer_cluster" title="Computer cluster">Computer cluster</a>

<ul><li><a href="Beowulf_cluster" title="Beowulf cluster">Beowulf cluster</a></li></ul></li>

<li><a href="Grid_computing" title="Grid computing">Grid computer</a></li>

<li><a href="Hardware_acceleration" title="Hardware acceleration">Hardware acceleration</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="API" title="API">APIs</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Ateji_PX" title="Ateji PX">Ateji PX</a></li>

<li><a href="Boost_(C%2B%2B_libraries)" title="Boost (C++ libraries)">Boost</a></li>

<li><a href="Chapel_(programming_language)" title="Chapel (programming language)">Chapel</a></li>

<li><a href="Charm%2B%2B" title="Charm++">Charm++</a></li>

<li><a href="Coarray_Fortran" title="Coarray Fortran">Coarray Fortran</a></li>

<li><a href="Dryad_(programming)" title="Dryad (programming)">Dryad</a></li>

<li><a href="Global_Arrays" title="Global Arrays">Global Arrays</a></li>

<li><a href="GPUOpen" title="GPUOpen">GPUOpen</a></li>

<li><a href="OpenMP" title="OpenMP">OpenMP</a></li>

<li><a href="OpenCL" title="OpenCL">OpenCL</a></li>

<li><a href="OpenHMPP" title="OpenHMPP">OpenHMPP</a></li>

<li><a href="OpenACC" title="OpenACC">OpenACC</a></li>

<li><a href="Parallel_Extensions" title="Parallel Extensions">Parallel Extensions</a></li>

<li><a href="Pthreads" title="Pthreads">pthreads</a></li>

<li><a href="RaftLib" title="RaftLib">RaftLib</a></li>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Problems</th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Automatic_parallelization" title="Automatic parallelization">Automatic parallelization</a></li>

<li><a href="Deadlock_(computer_science)" title="Deadlock (computer science)">Deadlock</a></li>

<li><a href="Deterministic_algorithm" title="Deterministic algorithm">Deterministic algorithm</a></li>

<li><a href="Embarrassingly_parallel" title="Embarrassingly parallel">Embarrassingly parallel</a></li>

<li><a href="Parallel_slowdown" title="Parallel slowdown">Parallel slowdown</a></li>

<li><a href="Race_condition" title="Race condition">Race condition</a></li>

<li><a href="Software_lockout" title="Software lockout">Software lockout</a></li>

<li><a href="Scalability" title="Scalability">Scalability</a></li>

<li><a href="Starvation_(computer_science)" title="Starvation (computer science)">Starvation</a></li></ul>

</div></td></tr><tr><td class="navbox-abovebelow" colspan="2"><div>

<ul><li> Category: Parallel computing</li></ul>

</div></td></tr></tbody></table></div></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-08-06" href="https://en.wikipedia.org/wiki/?title=Stream_processing&oldid=1304508329">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>